A serverless image resizing solution can be implemented by triggering an AWS Lambda function on S3 upload events to automatically process and resize images without managing servers.
A serverless image resizing solution using S3 and Lambda creates an automated event-driven pipeline. When a user uploads an image to a source S3 bucket, it triggers a Lambda function that processes the image (resizing, compressing) and saves the result to a destination bucket or folder. This architecture scales automatically, costs only when files are processed, and requires zero server management .
The core architectural pattern uses two separate S3 buckets or folders to prevent infinite loops. If the Lambda function wrote resized images back to the same bucket that triggered it, each new output would trigger the function again, causing an endless cycle. Therefore, best practice is to maintain an 'original' bucket for uploads and a separate 'resized' bucket for processed images . For even more flexibility, you can enable EventBridge for advanced filtering and routing of events to multiple Lambda functions .
The Lambda function needs appropriate IAM permissions to read from the source bucket and write to the destination bucket. It also requires the AWSLambdaBasicExecutionRole policy to write logs to CloudWatch for monitoring and troubleshooting. The function code typically uses image processing libraries like Pillow (PIL) for Python or Sharp for Node.js, which must be included in the deployment package or added via Lambda Layers .
To set up the S3 trigger, navigate to your source bucket's properties, configure an event notification for 'All object create events' (or specific suffixes like .jpg, .png), and select your Lambda function as the destination . Alternatively, you can enable EventBridge for the bucket and create rules that provide richer filtering capabilities, such as triggering only for files above a certain size or with specific metadata tags .
For production deployments, consider several optimizations: implement proper error handling with try/catch blocks, set appropriate Lambda timeouts (10-30 seconds for image processing), use temporary /tmp storage for intermediate files (limited to 512MB-10GB depending on configuration), and monitor CloudWatch logs for troubleshooting . You can also implement multiple resize configurations to generate several image sizes from a single upload, creating thumbnails, medium-sized images, and full-resolution optimized versions .
Always use separate source and destination buckets or folders to prevent infinite processing loops
Package image processing libraries (Pillow, Sharp, ImageMagick) via Lambda Layers or container images
Configure minimum IAM permissions: s3:GetObject on source bucket, s3:PutObject on destination bucket, and CloudWatch logs access
Set memory allocation appropriately (512MB-1GB) for image processing performance
Consider S3 Object Lambda as an alternative for on-the-fly transformations without storing multiple versions
Use CloudFront to serve resized images with caching for better performance